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Abstract 

The recurrent theme of this paper is that sequences of long tempo- 
ral patterns as opposed to sequences of simple statements are to be fed 
into computation devices, being them (new proposed) models for brain 
activity or multi-core/many-core computers. In such models, parts of 
these long temporal patterns are already committed while other are 
predicted. This combination of matching patterns and making pre- 
dictions appears as a key element in producing intelligent processing 
in brain models and getting efficient speculative execution on multi- 
core/many-core computers. A bridge between these far-apart models 
of computation could be provided by appropriate design of massively 
parallel, interactive programming languages. Agapia is a recently pro- 
posed language of this kind, where user controlled long high-level tem- 
poral structures occur at the interaction interfaces of processes. In 
this paper Agapia is used to link HTMs brain models with TRIPS 
multi-core/many-corc architectures. 

1 Introduction 



We live in a paradox. On the one hand, recent technological advances sug- 
gest the possible transition to powerful multi-core/many-core computers in 
the near future. However, in order to be economically viable, such a major 
shift must be accompanied with a similar shift in software, where parallel 
programming should enter the mainstream of programming practice becom- 
ing the rule rather than the exception. Briefly, programs eager for more 
computing power are badly needed. On the other hand, there is a critical 
view that the promises of AI (Artificial Intelligence) are still to be fulfilled. 
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No matter how much computer power we would have, the critics say, the 
advances in key AI areas as image recognition or understanding spoken lan- 
guages will be slow. This means that the current AI approach is, according 
to critics, faulty. 

AI already had a major restructuring in the nineties, by adopting the 
agent-oriented paradigm as a major research topic0 Jeff Hawkins [6] pro- 
poses another restructuring of AI by taking a closer look to the human brain. 
According to Hawkins, the efficient modelling of the human brain is of cru- 
cial importance if we really want to understand why human beings are so 
powerful on recognizing images or performing other similar tasks for which 
computers are still notoriously weak. Following suggestions provided by the 
anatomical structure of the brain, he proposes to use HTMs (Hierarchical 
Temporal Memories), hierarchical networks of nodes which work together 
processing continuous flows of data. While most of the pieces have been 
already used by other approaches (neural networks, associative memories, 
learning machines, interactive computing models, etc.), Hawkins stresses 
out the importance of having a unitary, coherent approach. In his view, 
the interplay between a systematic study of the brain and a creative design 
approach for developing intelligent machines is the solution to the current 
AI crisis. 

Our paper briefly presents HTMs and other key elements of Hawkins 
model of the brain [6]. Furthermore, it describes the specific features of a 
particular architecture called TRIPS (Tera-op, Reliable, Intelligently adap- 
tive Processing System) for multi-core/many-core computers [T]. The main 
contribution of the paper might be the suggestion that Agapia, a recently 
proposed language for massively parallel, interactive programs [HE], or sim- 
ilar languages, can potentially be a bridge between brain models, such as 
those using HTMs, and multi-core/many-core computers, particularly those 
using the TRIPS architectures. To strengthen the suggestion, the paper 
shows how Agapia programs for modeling HTMs can be developed and 
sketches an approach for compiling and running Agapia programs on TRIPS 
computers. 

2 HTMs - models for brain activity 

Understanding brain activity was and still is so difficult that even specu- 
lative theories on "how the brain could work" are rare. In a recent book 
"On Intelligence" [B], Hawkins proposes a computation model that may ex- 
plain the striking differences between the current computers and the brain 
capabilities, especially in such areas as visual pattern recognition, under- 
standing spoken language, recognizing and manipulating objects by touch, 

^See [2] for a recent presentation, centered on the use of agents for cooperative design 
in a distributed environment. 
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etc. Hawkins includes a rich set of biological evidences on the anatomical 
structure of the brain that may support his computation model. 

The model uses HTMs (Hierarchical Temporal Memories) to build up in- 
telligent devices. HTMs consist of hierarchical tree-like P2P (Peer-To-Peer) 
networks where each node runs a similar learning and predicting algorithm. 
The adequacy of these HTMs to discover the hidden structure of our outside 
world lies in the belief on the hierarchical structure of the world itself. 

Fig. [1] illustrates various types of HTMs. On the left, they are simple 
tree structures. On the right, an example of an HTM with shared subtrees 
is given. This latter example shows that generally HTMs could have a DAG 
(Directly Acyclic Graph) structure. However, as the processing flow may 
go up and down, or even between nodes at the same level, the resulting 
graphs are pretty general. The hierarchical structure is useful mostly as a 
conceptual approach for understanding the complicated structure and the 
complex activity of the brain. 



Getting the right level of processing. Briefly, the activity of a mature 
brain is as follows. At each node, sequences of temporal patterns arrive and 
are classified according to a learned schema. When this process is fully done, 
the patterns are replaced by short codes of the classes they were classified 
into and the sequences of these codes are forwarded to an upper node in the 
HTM hierarchy. This resembles the situation in a hierarchically structured 
company where an employee tells his/her superior "I have done this and 
this and this...," without entering into details. During the classification 
process, a node may look at a few starting temporal data from its incoming 
pattern, guesses the class the pattern falls into, and predicts the rest of 
the sequence. This gives a robust processing in the case the input data are 
partially ambiguous or have errors. 

Except for the explained forward flow of information in a HTM, there 
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is also a feedback flow from upper to lower nodes in the hierarchy. In the 
case a pattern can not be certainly classified by a node, the node might 
forward the full pattern to his/her upper node in the HTM hierarchy asking 
for help. Using the above analogy, this is like an employee telling his/her 
superior "You see, I do not know what to do in this case. Could you help 
me?" Depending on the experience of the HTM (or of the brain that the 
HTM models), the right level of processing the input patterns may be at 
a lower or a higher level in the hierarchy. Experienced HTMs/brains tend 
to fully process the input patterns at lower levels, while inexperienced ones, 
for instance those found in a learning process, tend to process the input 
patterns at higher levels in the hierarchy. Once a learned process is stable 
at a hierarchy level, it can be shifted "down to the hierarchy" for latter 
processing. This way, upper levels of the hierarchy become free and may 
process more abstract patterns, concepts, or thoughts. 

Associations. The focus in the previous paragraph was on the vertical 
structure in this HTM hierarchical model of the brain: how to learn and 
classify the incoming pattern in isolation. Actually, the brain and the corre- 
sponding HTM models have very powerful association mechanisms. These 
association mechanisms act either directly at a given level in a hierarchy 
(nodes are informed on the activity of their close neighbors), or far-apart 
via the hierarchical structure. In the latter case, information from different 
sensory systems may be combined (e.g., simultaneous recognition of sounds 
and visual images) for a better and faster processing. 

Perception and action. While most of the intuition behind the above 
examples comes from the human perception system, this HTM model of the 
brain makes no difference between the perception and the action mecha- 
nisms: the same kind of hierarchal structure and the same processing mech- 
anisms are present in the motor areas where brain thoughts are translated 
into visible behaviors. 

Numenta and intelligent machines. The pitfalls of Hawkins' approach 
may come from the yet-to-be-discovered learning and predicting algorithm 
used in the nodes of the HTM models of the brain. While this might take 
long and might be very difficult to discover, actually Hawkins has paved an- 
other way focusing on using HTMs to build "intelligent machines." His new 
company Numenta is planing to build computing chips based on HTM mod- 
els and using appropriate learning algorithms. Whether these algorithms do 
fit or not with the ones used by the brain may be irrelevant - in design, we 
do not have to copy the nature: our cars have no legs, our planes have not 
bird-like wings. 
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Turing test on intelligence. We close this brief presentation of Hawkins' 
model of the brain with a more philosophical discussion. What is "intelli- 
gence" and what it means for a computer to be "as intelligent as a human 
being" were (and still are) long debated questions. Alan Turing has invented 
Turing machines, a mechanical model of computation on which the modern 
computers are based. Turing has proposed this famous Turing test: a com- 
puter is as intelligent as a human being if it is behaviorally equivalent with a 
human being. In other words, an external observer can not see a difference 
between his/her interaction with a computer or with a human being. 

Searle, a fervent critic of this kind of intelligence test, came up with 
a "Chinese Room" thought experiment, showing that an English-speaking 
person following a set of rules (the analogy of a computer program) can 
properly answer Chinese-written questions without actually understanding 
Chinese. His conclusion is that intelligence and understanding can not be 
reduced to behavior. 

Hawkins' model places more emphasis on "prediction" in his attempt to 
capture a definition for intelligence. Understanding is closely linked with 
the capacity of prediction. Ultimately, understanding and intelligence may 
be completely internal, in the brain, without any visible external behavior. 

Ironically, the seminal paper of Turing contains a remark saying that 
what he has introduced is an a-machine, an autonomous one, and there is 
another notion of s-machine, an interactive one, which was not considered 
there. This difference between a closed and an open (interactive) approach 
may explain the main difference between Turing and Hawkins: Turing has 
used his autonomous machine reducing intelligence to its external behav- 
ior, while Hawkins uses an interactive approach with a sophisticated dance 
between the processing of the real input patterns and what the machine 
expects from its own prediction. 

3 Agapia - a parallel, interactive programming lan- 
guage 

Interactive computing [5] is a step forward on system modularization. The 
approach allows to describe parts of the systems and to verify them in an 
open environment. A model for interactive computing systems (consisting 
of interactive systems with registers and voices - rv-systems) and a core pro- 
gramming language (for developing rv-programs) have been proposed in [8] 
based on register machines and a space-time duality transformation. Struc- 
tured programming techniques for rv-systems and a kernel programming 
language Agapia have been later introduced [1], with a particular emphasis 
on developing a structural spatial programming discipline. 

Structured process interaction greatly simplifies the construction and 
the analysis of interactive programs. For instance, method invocation in 
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current 00-programming techniques may produce unstructured interaction 
patterns, with free goto's from a process to another and should be avoided. 
Compared with other interaction or coordination calcuh, the rv-systems ap- 
proach paves the way towards a name-free calculus and facilitates the devel- 
opment of a modular reasoning with good expectations for proof scalability 
to systems with thousands of processes. A new and key element in this 
structured interaction model is the extension of temporal data types used 
on interaction interfaces. These new temporal data types (including voices 
as a time-dual version of registers) may be implemented on top of streams 
as the usual data types are implemented on top of Turing tapes. 

Agapia [U [7] is a kernel high-level massively parallel programming lan- 
guage for interactive computation. It can be seen as a coordination lan- 
guage on top of imperative or functional programming languages as C++, 
Java, Scheme, etc. Typical Agapia programs describe open processes located 
at various sites and having their temporal windows of adequate reaction 
to the environment. The language naturally supports process migration, 
structured interaction, and deployment of components on heterogeneous 
machines. Despite of allowing these high-level features, the language can 
be given simple denotational and operational semantics based on scenarios 
(scenarios are two-dimensional running patterns; they can be seen as the 
closure with respect to a space-time duality transformation of the running 
paths used to define operational semantics of sequential programs). 

3.1 Scenarios 

This subsection briefly presents temporal data, grids, scenarios, and opera- 
tions on scenarios. 

Temporal data. What we call "spatial data" are just the usual data oc- 
curring in imperative programming. For them, common data structures 
and the usual memory representation may be used. On the other hand, 
"temporal data" is a name we use for a new kind of (high-level) tempo- 
ral data implemented on streams. A stream is a sequence of data ordered 
in time. (The time model in Agapia is discrete.) Typically, a stream re- 
sults by observing data transmitted along a channel: it exhibits a datum 
(corresponding to the channel type) at each clock cycle. 

A voice is defined as the time-dual of a register: It is a temporal data 
structure that holds a natural number. It can be used ("heard") at various 
locations. At each location it displays a particular value. 

Voices may be implemented on top of a stream in a similar way regis- 
ters are implemented on top of a Turing tape, for instance specifying their 
starting time and their length. Most of usual data structures have natural 
temporal representations. Examples include timed booleans, timed integers, 
timed arrays of timed integers, etc. 
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Figure 2: A grid (a), an abstract scenario (b), and a concrete scenario (c). 

Grids and scenarios. A grid is a rectangular two-dimensional array con- 
taining letters in a given alphabet. A grid example is presented in Fig.[2|^a). 
The default interpretation is that columns correspond to processes, the top- 
to-bottom order describing their progress in time. The left-to-right order 
corresponds to process interaction in a nonhlocking message passing disci- 
pline: a process sends a message to the right, then it resumes its execution. 

A scenario is a grid enriched with data around each letter. The data 
may be given in an abstract form as in Fig. E^b), or in a more detailed form 
as in Fig. [2]^c). 

The type of a scenario interface is represented as ti; ^2; • • • ; ^fci where each 
tk is a tuple of simple types used at the borders of scenario cells. The empty 
tuple is also written or nil and can be freely inserted to or omitted form 
such descriptions. The type of a scenario is specified as / : {w\n) — > (e|s), 
where w, n, e, s are the types for its west, north, east, south interfaces. 

Operations with scenarios. Two scenario interfaces t = ti;t2; ■ ■ ■ ',tk 
and t' = t[] t'2; . . . ; t'j^i are equal, written t = t', ii k = k' and the types 
and the values of each pair ti,t'- are equal. Two interfaces are equal up 
to the insertion of nil elements, written t =„ t' , if they become equal by 
appropriate insertions of nil elements. 

Let Idm,p '■ {m\p) {m\p) denote the constant cells whose temporal and 
spatial outputs are the same as their temporal and spatial inputs, respec- 
tively; an example is the center cell in Fig. El^c), namely Idi^2- 

Horizontal composition: Let fi : {wi\ni) — > {ei\si),i = 1,2 be two sce- 
narios. Their horizontal composition fi >/2 is defined only if ei W2- For 
each inserted nil element in an interface (to make the interfaces ei and W2 
equal), a dummy row is inserted in the corresponding scenario, resulting a 
scenario fi. The result /i i> /2 is obtained putting fi on left of f2- The 
operation is briefly illustrated Fig. [3jb). The result is unique up to insertion 
or deletion of dummy rows. Its identities are Idmfi^rn > 0. 

Vertical composition: The definition of vertical composition fi ■ f2 (see 
Fig. El^a)) is similar, but now using the vertical dimension. Its identities are 
Ido,m,'m > 0. 

Diagonal composition: The diagonal composition fi • f2 (see Fig. El^c)) 



111 
AaBbBbB 

2 11 
AcAaBbB 

2 2 1 
AcAcAaB 

2 2 2 



(b) 




7 



X 



S-3g ^^o^^g; 

-(a) (b) (onBS □ ^ 



Figure 3: Operations on scenarios 



is a derived operation defined only if ei =n W2 and si =„ n2. Tlie result is 
defined by the formula 

/l • /2 = (/l > > A) • (^2 > /C? > i?2) • (A > Si > /2). 

for appropriate constants R, S, Id, A. Its identities are Idm,n, m,n > 0. (The 
involved constants R,S,Id,A are described below.) 

Constants: Except for the defined identities, we use a few more con- 
stants. Most of them can be found in Fig. [3|^c): a recorder R (2nd cell in 
the 1st row), a speaker S (1st cell in the 2nd row), an empty cell A (3rd 
cell in the 1st row). Other constants of interest are: transformed recorders 
Fig. Ell^e) and transformed speakers Fig. [3l|^g). 



3.2 Structured rv-programs 

The syntax of structured rv-programs. The basic blocks for con- 
structing structured rv-programs are called modules. A module gets input 
data from its west and north interfaces, process them (applying the module's 
code), and delivers the computed outputs to its east and south interfaces. 

On top of modules, structured rv-programs are built up using "if" and 
both, composition and iterated composition statements for the vertical, the 
horizontal, and the diagonal directions. The composition statements cap- 
ture at the program level the corresponding operations on scenarios. The 
iteration statements are also called the temporal, the spatial, and the spatio- 
temporal while statements - their scenario meaning is described below. 

The syntax for structured rv-programs is given by the following BNF 
grammar 

P::=X \ if{C)then{P}dse{P}\ P%P \ P#P \ P$P 

I whileJ{C){P} I while_s{C){P}\ while_st{C){P} 

X ::= module{listen t_vars}{read sjvars} 
{code; }{speak t_vars}{write S-vars} 

This is a core definition of structured rv-programs, as no data types or 
language for module's code are specified. Agapia, to be shortly presented, 
is a concrete incarnation of structured rv-programs into a fully running 
environment. 
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Figure 4: The vertical and the horizontal compositions and the "if" state- 
ment 



Notice that we use a different notation for the composition operators 
on scenarios •, t>, • and on programs %, $; moreover, the extension of the 
usual composition operator ';' to structured rv-programs is denoted by "%". 

Operational semantics. The operational semantics 

I I : Structured rv-programs Scenarios 

associates to each program the set of its running scenarios. 

The type of a program P is denoted P : {w{P)\n{P)) — > (e(P)|s(P)), 
where w{P) / n{P) / e{P) / s{P) indicate its types at the west /north/east /south 
borders. On each border, the type may be quite complex - the convention 
is to separate by "," the data from within a module and by ";" the data 
coming from different modules. This convention applies to both spatial and 
temporal data. 

We say, two interface types match if they have a nonempty intersection. 

Modules. The modules are the starting blocks for building structured 
rv-programs. The listen (read) instruction is used to get the temporal 
(spatial) input and the speak (write) instruction to return the temporal 
(spatial) output. The code consists of simple instructions as in the C code. 
No distinction between temporal and spatial variables is made within a 
module. 

A scenario for a module consists of a unique cell, with concrete data on 
the borders, and such that the output data are obtained from the input data 
applying the module's code. 

Composition. Programs may be composed "horizontally" and "vertically" 
as long as their types on the connecting interfaces agree. They can also be 
composed "diagonally" by mixing the horizontal and vertical compositions. 

For two programs Pi : {wi\ni) {ei\si), i = 1,2 we define the following 
composition operators. 

Horizontal composition: Pi#P2 is defined if the interfaces ei and W2 
match, see Fig. ID^middle). The type of the composite is {wi\ni;n2) — 
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(e2|si;s2)- A scenario for Pi#P2 is a horizontal composition of a scenario 
in Pi and a scenario in P2. 

Vertical composition: Pi%P2 is similar. 

Diagonal composition: Pi$P2 is defined if ei matches W2 and si matches 
n2- The type of the composite is {wi\ni) — > (e2|s2). A scenario for Pi$P2 is 
a diagonal composition of a scenario in Pi and a scenario in P2. 

If. For two programs Pi : (zt;i|nj) — {ei\si), i = 1,2, a new program 
Q = if (C) then {Pi} else {P2} is constructed, where C is a condition 
involving both, the temporal variables in wi D W2 and the spatial variables 
in riinn2, see Fig. [Upright). The type of the result is Q : {wiUw2\niUn2) —> 
(ei U e2|si U 52)- 

A scenario for Q is a scenario of Pi when the data on west and north 
borders of the scenario satisfy condition C, otherwise is a scenario of P2 
(with these data on these borders). 

While. Three types of while statements are used for defining structured 
rv-programs, each being the iteration of a corresponding composition oper- 
ation. 

Temporal while: For P : {w\n) {e\s), the statement whileJ. (C){P} is 
defined if the interfaces n and s match and C is a condition on the spatial 
variables in n n s. The type of the result is {{w; )*|n U s) ^ ((e; )*|n U s). 
A scenario for while J, (C){P} is either an identity, or a repeated vertical 
composition /i • /2 • • • • • /fc of scenarios for P such that: (1) the north border 
of each /j satisfies C and (2) the south border of fk does not satisfy C. 

Spatial while: whiles (C){P} is similar. 

Spatio-temporal while: whilest (C){P}, where P : {w\n) — > (e|s), is 
defined if w matches e and n matches s and, moreover, C is a condition on 
the temporal variables in w He and the spatial variables in nO s. The type 
of the result is {wL)e\nL) s) — > {wUe\nL)s). A scenario for whilest (C){P} 
is either an identity, or a repeated diagonal composition /i • /2 • • • • • /fe of 
scenarios for P such that: (1) the west and north border of each fi satisfies 
C and (2) the east and south border of fk does not satisfy C. 

3.3 Agapia 

Syntax of Agapia vO.l programming language. The syntax for Agapia 
vO.l programs is presented in Fig. O The vO.l version is intentionally kept 
simple to illustrate the key features of the approach (see [7] for an exten- 
sion vO.2 including high-level structured rv-programs). Agapia vO.l forms a 
kind of minimal interactive programming languages: it describes what can 
be obtained from classical while programs allowing for spatial and temporal 
integer and boolean types and closing everything with respect to space-time 
duality. 
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E -.--nlV \ E + E \ E*E \ E - E \ E/E 
B -.--blV \ B&c&cB I B\\B \ \B\ E <E 

Programs 

W :■- nil I new x : SST \ new x : STT 
\x--E\ if{B){W}else{W} 
\W;W \ while{B){W} 
M :■- module{liaten x : STT}{read x : SST} 
{W; }{speak x : STT}{write x : SST} 

P :■- nil I M I if{B){P}else{P} 
\ P%P \ P#P 1 P$P 
I whileJ{B){P} I while^{B){P} 
while.st{B){P} 

Figure 5: The syntax of Agapia vO.l programs 

The types for spatial interfaces are built up starting with integer and 
boolean sn,sb types, applying the rules for U, ',')(-)* to get process inter- 
faces, then the rules for U, (-j )* to get system interfaces. The temporal 
types are similarly introduced. For a spatial or temporal type V, the no- 
tations V{k), V.k, V.[k], V@k, V@[k] are used to access its components. Ex- 
pressions, usual while programs, modules, and programs are then naturally 
introduced. 

4 Agapia programs for HTMs models 

The current approach is to give Agapia scenario-based semantics with linear 
models for space and time. When different models are needed, as tree models 
for the HTMs presented in this paper, a linear representation of such models 
is required. Fortunately, there is a huge amount of work on similar topics 
involving representation of an endless number of data structures in the linear 
virtual memory model of conventional computers. 

We focus our design of Agapia programs below on the HTM in the left 
side of Fig. [T] (the regular hierarchy, restricted to 2 levels: top, level 1, level 
2) considered as a HTM model for a part of a visual sensory system. 

Tree structures are represented recursively labeling their nodes by strings 
as follows: "if a node p in the tree is labelled by w and a node q in the tree 
is his/her i-th son (direct descendent), counting the positions from left to 
right, then the code of q is tyi." 

In our example, the codes of the nodes are: nil (for the top node), 

I, 2,3 (for the nodes on level 1), and 11,12,21,22,31,32 (for the nodes on 
level 2). The nodes are placed in a linear order using an extension of 
the Left-Right-Root parsing in binary trees. In our case the result is: 

II, 12, 1,21, 22, 2, 31, 32, 3, nil. With this convention, it is easier to describe 
Agapia programs for the forward flow of information, but slightly more 



Interfaces 

SST :■- nil \sn\sb\ {SST U SST) 
[SST, SST) I (SST)* 

ST :■- (SST) I (STUST) 
(ST; ST) I {ST;)* 

STT :■- nil \ tn \ tb \ {STT U STT) 
{STT, STT) I {STT)* 

TT :■- {STT) I (TTUTT) 
I (TT;TT) I (TT;)* 

Expressions 

V ::= x : ST \ X -.TT \ V{k) 

V.k I V.[k] I V@k I V@[k] 
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complicated for the feedback flow. In the sequel, we suppose each process 
knows his/her code in the list and the codes of other nodes in the structure. 

Our approach to modeling HTMs with Agapia programs consists of three 
steps. 

The first step requires more or less conventional programming for the 
basic modules. As one can develop Agapia on top of C++ or Java, code in 
such languages could be used in these modules. The code has to implement 
the following features. 

1. Each node has a classifying algorithm, for instance using a "typical 
representative" for each class. Suppose the classes are {Ci, . . . ,Cn} 
and their representatives are {ti, . . . ,tn}- Given a temporal pattern 
t (a voice, or a more complex temporal data structure) the node find 
the best matching of t against ti, . . . ,t„. According to Hawkins, this 
classification should be unique. However, increasingly sophisticated 
procedures may be used to reach this result, for instance using the 
feedback fiow from top-to-bottom in the hierarchy or the association 
flow from the neighboring nodes. 

2. An alternative to the best full matching is to use a prefix matching: 
once a prefix of t was parsed and it fits with a unique tj, then the rest 
of t is ignored. 

3. Each class Ci is supposed to have a name nj (codified with much 
shorter sequences than for t or tj's). The final product of the node is 
the passing of the code Uk of the class Ck for which t has the best fit 
to his/her HTM parent. 

4. In contrast with 2, another alternative is to have fully attentive nodes, 
keeping track on all details. In such if the input pattern does 
fit well with none of tj's, the node passes the full t (not just a code for 
his/her better fitting class) to his/her parent for further processing. 

5. Finally, higher level nodes, except for their own classification, have to 
process the exceptions in the classification procedures of their descen- 
dent nodes. 

The second step is to describe the forward fiow of information in this 
HTM. It is just a particular format of MPI-like communication mechanisms 
for which Agapia macro-programs can be easily written (see, e.g., The 
shape of the program is as follows. 

1. The program contains a main diagonal while statement. It repeats the 
processing for repeated incoming temporal patterns t's. 

2. During a step of the diagonal while statement, each node gets input 
patterns from the left, processes them, and passes the results to the 
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right. This means, for the leaves the input data come from outside 
(from the open temporal interfaces), while for the inner nodes they 
come from their own descendents. The results are passed to the par- 
ents, which fortunately are placed on the right in this linear order of 
the nodes. This way, when a body of the diagonal while statement is 
executed, the forward flow in the HTM is fully modeled. 

The third step is to show how the feedback flow in the HTM can be 
modeled. This is slightly more complicated, as we have chosen a linear order 
to facilitate the modeling of the forward flow. Indeed, as the interaction 
in Agapia programs goes from left to right, when a parent node wants to 
send a message to a son, an extra diagonal composition is needed to model 
this communication. Except for the extra diagonal composition steps, the 
modeling of the interaction is similar to the previous case. 

5 TRIPS - a multi-core/many-core architecture 

With a privileged role between programming languages and hardware, the 
instruction set used in computer architecture design is very conservative. 
Changing or introducing new ISA (Instruction Set Architecture) is disrup- 
tive for computer systems and may be very risky. Nevertheless, the time 
for a radical change is imperative. The old CISC/RISC instruction sets no 
longer fit with the huge potential of the forthcoming multi-core/many-core 
computers. Introducing new ISA is now worthwhile having the potential to 
address the challenges of modern technologies and to exploit various integra- 
tion possibilities [1]. In this context, TRIPS (Tera- op, Reliable, Intelligently 
adaptive Processing System) architectures are a very promising recent pro- 
posal facilitating higher exploitation of data, instruction-level, and thread- 
level parallelisms [10]. 

TRIPS is an instantiation of the EDGE (Explicit Data Graph Execution) 
ISA concept. EDGE is a new class of IS As that views an instruction stream 
as blocks of instructions for a single task using isolated data. The main 
feature of an EDGE architecture refers to direct instruction communication 
which enables a dataflow-like execution. Unlike RISC and CISC instruction 
sets, EDGE explicitly encodes dependences into individual instructions. The 
hardware is not required to rediscover data dependences dynamically at run- 
time because the compile-time dependence graph is expressed through the 
ISA. Higher exposed concurrency and power-efficient execution are therefore 
facilitated by an EDGE architecture [T]. EDGE overcomes major drawback 
issues of the RISC and CISC architectures such as the usage of inefficient 
and power-consuming structures. 

Offering increased flexibility, TRIPS supports a static placement of in- 
structions (driven by compiler) and dynamic issue (hardware-determined) 



13 



execution model. Graphs of predicated hyperblocks are compiled and repre- 
sented internally as a dataflow graph. Communication between hyperblocks 
is possible via a set of input and output registers. 

The TRIPS architecture aims to increase concurrency, to achieve power- 
efficient high performance and to diminish communication delays. Concur- 
rency is increased by using an array of arithmetic logic units (ALUs) exe- 
cuted concurrently. ALUs provide scalable issue width as well as scalable 
instruction window size [1]. The TRIPS architecture minimizes execution 
delays by using compile-time instruction placement. Computation patterns 
are efficiently supported by the dataflow-like execution model of TRIPS. 

The block-atomic execution engaged in TRIPS works as follows |T]: 

• Instructions are grouped by the compiler into groups of instructions 
called hyperblocks (each hyperblock contains up to 128 instructions) 
and mapped to an array of execution units; 

• Each hyperblock is fetched, executed, and committed atomically; in- 
structions are fetched in parallel and loaded into the instruction buffers 
at each ALU; 

• Instructions are efficiently executed by the hardware using a fine- 
grained dataflow model. 

TRIPS can effectively support parallelism (instruction-level, data-level, 
and thread- level parallelism). As long as the software can discover paral- 
lelism, the TRIPS architecture will effectively exploit it. Being easy to scale 
up and down in performance, TRIPS overcomes the scheduling problems of 
traditional designs as well as the explicit unit exposure of VLIW (Very Long 
Instruction Word) designs. 

6 Running Agapia programs on TRIPS architec- 
tures 

We end our trip from brain models to multi-core/many-core computers with 
some remarks on the possibility of compiling and running Agapia programs 
on TRIPS architectures. 

To illustrate the approach, we consider a simple example involving per- 
fect numbers. A number is perfect if it is equal to the sum of its proper 
divisors. Before showing Agapia programs for perfect numbers, we describe 
two typical running scenarios for this task (one for a perfect number, the 
other for an imperfect one) in Fig. El The input-output relation is: if the 
input number in the upper-left corner is n, then the output number in the 
lower-right corner is iff n is perfect. 

The scenarios in Fig. [6] use cells whose behaviors are captured by the 
modules in Tabled) 
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x=6 




(a) (b) 
Figure 6: Scenarios for perfect numbers 

Our first Agapia program Perfect 1 corresponds to the construction of 
the scenarios by rows: 

(X # Y # Z) % while_t(x > 0){U # V # W} 

The type of the program is Perfect 1 : {nil\sn;nil;nil) — > {nil\sn; sn; sn) . 
Actually, the result is a program similar with a usual imperative program. 
There are some "transactions," each transaction specifying a macro-step 
in the whole system. The interaction part is simple and it reduces to the 
interaction of the components in a macro-step. 

Our second Agapia program Perfect2 corresponds to the construction 
of the scenarios by columns: 

(X % while_t(x > 0){U} 7. Ul) 

# (Y 7, while_t(tx > -1){V} 7. VI) 

# (Z 7. while_t(tx > -1){W} % Wl) 

Its type is Perfect2 : {nil\sn;nil;nil) {nil\nil;nil; sn) . This variant 
resembles the dataflow computation paradigm. Each component acts as a 
stream processing function and the overall result comes from the interaction 
of these components. 

The first program is appropriate for running on classical architectures, 
while the last one for dataflow architectures. TRIPS architecture is a com- 
bination of both. The current prototype uses sequences of up to 128 instruc- 
tions to feed its matrix of ALUs. Agapia is very flexible and expressive, for 
instance the above two programs are just the extreme cases of a rich variety 
of possibilities. More precisely, one could unroll the flrst program, or restrict 
the number of steps in each component in the second program to get pro- 
grams which flt better with the TRIPS architecture. Such transformations 
might be performed automatically to help the user to focus on the logic of 
the program and not on the target computer running his/her program. 

Compiling Agapia programs for TRIPS architecture is without a doubt 
a very challenging direction. While our intuition strongly supports such an 
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module Xjlisten nil;}{read x:sn;} 

{tx:tn; tx=x; x=x/2 ; }{speak tx;}{write x;} 
module Yjlisten tx : tn; }{read nil;} 

{y:sii; y=tx;}{speak tx;}{write y;} 
module Zjlisten tx:tn;}{read nil;} 

{z:sn; z=tx;}{speak nil;}{write z;} 
module Ujlisten nil;}{read x:sn;} 

{tx:tn; tx=x; x=x-l ; }{speak tx;}{write x;} 
module Vjlisten tx:tn;}{read y:sn;} 

{if (y7.tx != 0) tx=0;}{speak tx;}{write y;} 
module Wjlisten tx:tn;}{read z:sn} 

{z=z-tx; }{speak nil;}{write z;} 
module Uljlisten nil;}{read x:sn;} 

{tx:tn; tx=-l ; }{speak tx;}{write nil;} 
module Vljlisten tx:tn;}{read y:sn;} 

{null ; }{speak tx;}{write nil;} 
module Wl{listen tx:tn;}{read z:sn} 

{null ; }{speak nil;}{write z;} 



Table 1: Modules for "perfect numbers" programs 

attempt, the painful procedure of writing a compiler and running programs is 
actually needed to clarify how well Agapia language and TRIPS architecture 
fit together. 

7 Conclusions and future work 

Most programs for AI tasks are inefficient on traditional computers with 
their Von-Neumann architecture and using imperative programming style. 
The proposed dataflow machines from eighties and nineties, specific for AI 
tasks, never had a major impact on the market. What we see in the re- 
cently proposed TRIPS architectures is a combination of dataflow and Von- 
Neumann styles, particularly using speculative execution of long blocks of 
instructions on the computers' arrays of ALUs. 

The speculation on possible executions of the paths in a program, used 
to increase the processing speed, looks somehow similar to the prediction 
process in the HTM models of the brain. A comparison between these two 
computing models may be worthwhile for both fields. For instance, while the 
computer prediction is in the narrow window of the user program demand, 
the HTM models of the brain are more open, interactive, agent-like - here 
the prediction is mixed with possible actions of the human being who can 
change the course of the forthcoming input data. This may explain why 
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humans are good on interactive tasks, while current computers with their 
predefined program-captured behavior are not. 

We plan to develop the ideas from this paper in both directions: (1) to 
get a rich set of Agapia programs for HTMs models, particularly for those 
used by Numenta platform [9]; and (2) to explore the possibility of getting 
a running environment for Agapia programs on TRIPS computers |10j . 
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